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ABSTRACT 


This thesis is designed to present a detailed 
descripticn and analysis of the Naval Ccmmunications 
ProcesSing and Routing System (NAVCOMPARS). Discussed 
are the objectives and principles of the Naval 
Telecommunications Automation Program (NTAP), with 
emphasis flaced on delineating the shore components, 
particuiarily NAVCOMPARS. The capabilities of 
NAVCOMPARS are identified by describing the patterns 
of message flow through the automated system. Also 
considered are the manpower and training 
characteristics and the projected link with the 
Information Exchange Subsystem (IXS). A model of the 
central processing unit is presented in order to 
highlight the sequence of procedures employed by an 
automated message processing system. The underlying 
intent of this thesis is to provide a compact document 
which could be used aS introductory material to 
acquaint non-computer specialists With the 
characteristics, reguirements and potential of the 


Naval Communications Processing and Routing Systen. 
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The mission of naval telecommunicaticns is to supply 
accurate, secure, reiiable and rapid communications to naval 
forces and commands around the world. The Naval 
Telecommunications System (NTS) also has responsibilities as 
an integral part of the Defense Communications System 
Automatic Digital Network (AUTODIN), which provides a 
connection to the National Command Authority and the other 


military services. 


The prime element in judging the effectiveness of the 
NTS is the determination as to whether the system can 
transfer reguired information accurately and reliably from 
originator to addressee in an interval timely enough to be 
useful to the recipient. In the late 1960s, serious 
questions were raised concerning the ability of the NTS to 
meet the requirements imposed upon it. Delays which severly 
downgraded service below acceptable levels were occurring 
during message processing at originating and terminating 
communications centers, as well as in the points Of 
interface between fleet and shore systems. [In order to 
alleviate the delays which resulted through the inefficient 
and error prone procedures involved in manual processing of 
messages, emphasis was placed on developing and implementing 


automated message processing systems which would meet all 


the Navy's requirements for information transfer. This 
paper will examine the objectives of the Naval 
Telecommunications Automation Program (NTAP) and will 


describe the innovations in automated message handling 


procedures which have occurred in shore communications. 


le 





Detailed attention will be focused on the characteristics of 
the Naval Communications Processing and Routing System 
(NAVCOMPARS) . 
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Adoption of the Naval Telecommunications Automation Plan 
in 1971 established guidelines for the evolution of the NTS 
into an automated system which would satisfy the demands 


placed upon communication centers ashore and afloat. 


A. OBJECTIVES 


The specific objectives of the NTAP are as_ follows 
[Refs. 15 and 18]: 


ae Improve originator to addressee delivery times to 
meet designated standards. 


b. Obtain a timely exchange of information critical to 
the command and control of forces afloat through the 
automation of message processing functions. 


Cis Previde a capability to effect consolidation of 
telecommunication facilities and functions to allow 
Significant manpower and equipment savings. 


d. Eliminate current slow manual operations _ to reduce 
error rates and to allow more efficient utilization of 


personnel. 

e. Make Maximum use of high speed data 1links 
fae oun es) and rovide more efficient operation 
uring crises situations. 


Be. PLANNING FRINCIPLES 


Several principles were delineated tc govern the 
implementaticn of the NTAP. Due to the urgent nature of the 


requirements for automated processing systems and the 
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availability of commercial hardware, maximum use would be 
made of off-the-shelf hardware in order to decrease 
developmental cost and to permit the most cost-effective 
installation of the system. Hardware and software would be 
modular in design in order to ensure flexibility in the 
system, and procurement practices would be oriented toward 
Maintaining compatibility between subsystems, Consideration 
was to be given to utilizing, where possible, relatively 
simple input-output terminals which would operate under the 
control of a more sophisticated host processor. 
Additionally, systems would be ‘user transparent! to provide 
maximum usability with minimum training. Due to space 
limitations prevalent on a large number of ships, the NTAP 
stressed the regquirement that the maxinun number of 
communications functions would be performed ashore, thereby 


Minimizing the equipment inventories needed on board snips. 


C. COMPCNENTS OF THE SHORE ESTABLISHMENT 


The NTAP encompasses automation projects in shore 
communications, fleet communications and the interface 
betyeen the two, which is basically the Fleet Satellite 


Communications (FLTSATCOM) Program. Present planning calls 


for a shore subsystem to be composed of seventeen Local 


Digital Message Exchanges (LDMX) for major telecomaunication 
centers, five NAVCOMPARS for Naval Communication Stations 
(NAVCOMMSTA), and ninetyzfive Remote Information Exchange 
Terminals (RIXT) for small telecommunications centers in the 
immediate area of an LDMX/NAVCOMPARS. Each of these systems 
is designed to eliminate to the greatest extent possible 
Manual intervention in the processing of messages. RIXT is 
being devised to utilize an LDMX/NAVCOMPARS comptuter as a 
host for processing functions including message entry, 


logging, routing, formatting, file and retrieval. RIXT 
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installations at telecommunication centers will generally 
replace presently existing Autodin terminals. In order to 
comply with the planning principles of the NTAP, NAVCCMPARS 
software will be used on future LDMX systems, and presently 
operating LDMX sites will be transitioned to it. The LDMX 
at San Diego is currently operating with modified NAVCOMPARS 


software. 
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III. NAVCOMPARS SYSTEM DESCRIPTION 


A real-time systen devoted exclusively to naval 
telecommunication applications, NAVCGMPARS is a tactical 
System designed primarily to provide an automated fleet 
broadcast and an automated entry into Autodin. When 
FLTSATCOM is completely operational, NAVCOMPARS, in 
conjunction with Autodin, will enable ships to have the 
Capability for high speed point-to-point transmissions. 
NAVCOMPARS also provides administrative and service 


functions to over-the-counter (OTC) users. 


A. EQUIPMENT 


Due tc tke criticai nature of its command and control 
function as a link to the operating forces, NAVCCMPARS 
requires an extraordinary degree of system reliability. To 
provide for this key factor, NAVCOMPARS consists of a 
duplexed Univac series 70/45 systen. Under this duplexed 
configuration, one central processing unit and associated 
eguipment are on-line, while the second CPU iS maintained in 
the back-up mode. A nultiplexor is an integral part of the 
CPU and is capable of accomodating 256 devices in a wide 
Variety of configurations. Each CPU has communications 
capabilities when equipped with appropriate communications 
equipment. The communications module is composed of two 
multi-channel communications controllers, up to 82 teletype 
devices, two Dataspeed readers, an Optical Character Reader 
(OCR) and 10 Video Data Terminals (VDT). The Multi-channel 


Communications Controller (CCM) is a communications 


mi 





coordination device which provides a Capability to 
accomodate up to 48 half-duplex channels and provides the 
computer systems interface for the VDTs, dedicated channels, 
teletypewriter logs, medium speed readers, OCR, satellite 
and broadcast channels. [Refs. 15 and 16] A nemory 
protection feature, which allows up to sixteen levels of 
memory separation, maintains memory and program integrity in 
a multi-programming environment. The internal logic for 
elementary Oferations 1s contained in read-only memory. 


Software has been developed by Naval Command Systems 
Support Activity to accomodate the requirements of various 
actual and proposed locations; therefore, identical software 
has peen installed at all operating sites. Standardization 
Of software has been rigidly maintained, and systen 
modifications are implemented only as directed by program 
Changes from NAVCOSSACT. Flexibility has been built into 
the system through incorporation of a modular design, which 
for example will accept the program additions necessary for 
Satellite communications. Each subsystem must fit properly 
Within the total system, but the various subsystems were 
initially developed as separate sections of software. A 
dual file ccncept is utilized to provide a fall back 
capability. This is significant because it allows the 
back-up set cf routing files to be used for the daily update 
action while the on-line system is operating. 


Be. MESSAGE FLOW ANALYSIS 


NAVCOMPARS automates message processing activities in 
three areas of a NAVCOMMSTA: Fleet Center, Computer Center 
and MessageyService Center, In addition to the major 
function of automatically keying on-line the fleet 
broadcast, procedures managed by NAVCOMPARS include 
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preparation, rowerng, formatting, code conversion, 
validation, editing, transmission, filing, recalling, 
re-addressal and retransmission. The systen also 
distributes OTC traffic, handles data traffic, generates 
statistics and maintains a real-time fleet locator. Using 
Figure 1 as a reference source, this paper wiil detail the 
procedures involved in processing narrative traffic through 
the subsystems of a NAVCOMPARS. 


1. Message Entry 


Messages are entered in NAVCOMPARS through Autodin 
Switching Centers {ASC) , over-the~counter procedures 
(primarily OCR for narrative traffic), on-line 
dedicated/full period channels and off-line fuii period 


channels. 


ae Autodin 


Autodin messages in JANAP 128 format are 
received via the Autodin Interface Subsystem (AIS) which is 
resident in two Univac 70/1600 Autodin Communication 
Controllers. This digital stored program processor, which 
Supplies the connection between the ASC and NAVCCMPARS 


Maintains synchronization with the ASC, strips ccntrol 


characters from incoming line blocks and checks 
block/character parity. Under the dual homing concept, 
Simultaneous interfaces will be maintained with two 


different ASCs. 


The message then is received by the Autodin 
Control Subsystem (ACS), which is resident in the 70/45 
processor. ACS accepts mesSage input from AIS and then 


utilizes the Communications Control Subsystem (CCS) to 


to 
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notify the Receive Control Subsystem (RCS) of receipt of 
data. ACS acknowledges to AIS for each line block received; 
additionally, when an entire message is processed and 
accounted for by RCS, ACS will send an end of message (EOM) 
acknowledgement to the Autodin Controller. 


The RCS is an interrupt driven subsystem capable 
Seeimteritacing with all sources of input concurrently. ae 
is responsible for channel coordination to ensure that all 
traffic received is correctly identified and that any errors 
in sequence cf messages or SOM-EOM wiil be detected. After 
translating Autodin messages from ASCII to EBCDIC, RCS 
assigns each message a processing precedence and then. queues 
the message fcr the Message Processing Subsystem (MPS). RCS 
records each message received on two separate on-line disk 


files for recovery purposes in case of system failure. 


b. Cn-line 


Messages are entered into NAVCOMPARS on-line via 
OCk, on-line dedicated channels and full period 
terminations. On-line dedicated/full period channels can be 
landline channels to ships in port, electronic courier 
Circuits to on-base users or landline quality full period 
terminations to ships at sea. Satellite channels are 
expected to be of landline guality and will be on-line 
directly into NAVCOMPARS for both incoming and outgoing 
tracéédc.. 


The entry point for on-line traffic 1S via the 
GESi,, aly bach queues communications device interrupts, 
distributes these interrupts to the appropriate subsystem 
and checks for errors on communication devices. This 
subsystem supervises the logs generated by the teleprinter 


(Channel log, service log, outgoing log and temporary 


21 





Autodin log) and interfaces with the OCR, Dataspeed reader, 
VDT and on-line teletype. OCR messages are converted Ey RCS 
to modified ACP 126 format. The ASCII code used by the OCR 
is translated into EBCDIC. RCS then performs input 
processing corresponding to that performed on Autodin 


traffic on all the above categories of messages. 
C25 Off-line 


Off-line channels are high frequency radio 
channels which are not of suitable quality for direct 
interface into the system. Torn tape frocedures are 
utilized for the interface with NAVCOMPARS. Upon receipt, 
each message is visually screened. rf “the “message iis 
acceptable, it 1s entered into the system via nedium speed 
paper tape readers which interface with CCS. Messages are 
then passed to RCS for input processing and conversion of 
five level baudot code to EBCDIC. All narrative messages 
will be converted to one of two basic formats, JANAP 128 or 
modified ACP 126. Use of basic formats and a common data 
code, EBCDIC, allows for minimization of the nunmter of 


message analysis routines needed in processing. 


2. Message Processing 


Ccntrol of messages passes From RCS to the Message 
Processing Subsystem (MPS). NAVCOMPARS processes three 
forms of traffic: narrative, data pattern and readdressals. 
Readdressals are previously transmitted messages which are 
designated for transmission by one of the original 
recipients to a command not on the initial distribution. 
These messages require the generation of a new message 
header upon subsequent transmission. MPS is responsible for 


message analysis and functions such as fcrmat conversion 
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from modified ACP 126 to JANAP 128, header validation, 
routing indicator asSignment, susdupe processing to 
eliminate duplicate messages, broadcast guard List 
processing, generation of broadcast recap messages and 
determination of OTC and broadcast delivery requirements. 
Messages can ke recalled on-line for up to ten days and MPS 
will build and append headers for readdressal. The only 
processing dcne to the text of the message, other than 
classificaticn and special handling checks, is the insertion 
of the proper paging and sectioning information. MPS will 
display error conditions Ons specifically requested 
informaticn to the VDP operator in order to perform 
functions involved with message recalls, routing and 
distribution, file displays, channel status and control, 
message entry, broadcast screens and message editing. 
Changes in rcuting files can be entered on-line by the VDT 
Operator in order to effect immediate shift in guard list 
responsibilities. NAVCOMPARS possesses traffic managemenat 
features which permit the operators to closely monitor 
traffic queues and to establish alternative transmission 
paths to eliminate backlog conditions. Using a VDT, 
Supervisory personnel can visually inspect the queues 
existing on a specific channel and can activate rerouting 
procedures via VDT entered command. Separate queue reports 
can be displayed to show queue status for the total systen 
With a breakdown by processing step and precedence as well 
as the number of messages hy precedence being queued for 
each outgcing channel. 


The Transmission Processing Subsystem (TPS) receives 
message information from MPS, utilizing the delivery 
instructions generated by MPS to determine the destination 
queues to which the message will be Jlinked. Prior to 
assigning a message to a transmission channel queue, TPS 
ensures that the security classification of the channel 


matches that of the message. If a security mismatch exists, 


Zs 





the message 1S automatically delivered to either the Service 
Center Or Top Secret Control for alternate routing 
determination or off-line encryption. TPS coordinates the 
creation of journal entries after all destinations have 


received the message. 


Responsibility for the delivery of messages to a 
communications channel or terminal device is lodged in the 
Transmission Control Subsystem (TCS). This subsystem 
interfaces with the Service Center line printer, Message 
Center mat printer, paper tape punch, card punch, Top Secret 
courier, electronic courier circuits, broadcast channels, 
full pericd channels, dedicated channels and Autodin. TES 
provides for format and code conversion for the outgoing 
line, editing, routing line segregation and broadcast 
reruns. NAYCOMPARS processes messages by precedence ona 
first-in first-out basis. Provisions have been established 
for interruption by Emergency Command and FLASH messages. 
These messages will be retransmitted immediately after their 
Original tranasmissicn and again fifteen minutes later. fhe 
message interrupted for higher precedence CESLE VES is 
repositioned at the head of its respective quete and 1s 


retransmitted under a new number. 
ae Autodin/OTc 


Under the dual homing concept of operations, 
Simultaneous interfaces are maintained with two sefarate 
Autodin Switching Centers, and messages are automatically 
assigned to the appropriate channel. TCS interfaces with 
the Autodin Communications Controller through AIS. ACS 


generates Autodin log entries upon receiving acknowledgement 
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trom the ASC for SOM, EOM or cancellation. The NAVCOMMSTA 
Message Center retains responsibility for reproduction and 
Pierce ioueen of traific to OTC users. NAYCOMPARS can 
automatically distribute a specified number of copies to 
applicable ccmmands according to several arguments including 
standard subject identification code (SSIC) and flagwords, 
Or it can perform internal command distribution by cffice 
codes for designated users. When a message is printed at 
the mat printer, the system displays delivery lines, copy 
counts and internal distribution at the bottom of the first 
page of the message. At this point, the message is at the 
end of the automated process and probably has not been seen 
by anyone at the receiving communications center. One of 
the new billet descriptions for NAVCOMPARS calls for an 
editor whe will examine each message prior to reproduction 
in order to detect errors, such as garbles within the text, 


which would not have been identified by software processing. 


b. Fleet Broadcast 


NAVCOMPARS has the capability to automatically 
key up to seventeen channels of the fleet broadcast with 
both single and multi-channel circuits being keyed. Traffic 
on the broadcast will be in modified ACP 126 format; 
messages will be edited to delete format lines 1, 2, 3, 4, 
15, and all paging information. (See Figure 5 for an 
explanation cf modified ACP 126 format.) The system is 
structured so an operator can exercise control over the 
broadcast by VDT command to either hold traffic due to an 
outage Or to initiate altroute procedures to relieve 
Overloaded queves. A delayed rerun channel will normally be 
assigned fOr each first run traffic channel of a 
multi-channel broadcast with activation being accomplished 
by VDT ccmmand. An additional feature provides for 


automatic message rerun when no queue of first run traffic 
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exists. 


ce. On~linesOff-line Channels 


ish outgoing messages sent to channels of 
dedicated landline quality will be transmitted on-line by 
the system. Messages addressed to ships terminated off-line 
will be delivered to a low speed paper tape punch associated 
with each full period termination. An operator will 
manually perform the send operation, repeating transmission 
until the addressee acknowledges receipt of a legible copy. 
Prescribed format for poth on-line and off-line channels is 
JANAP 128 with non-pertinent routing indicators being 
automatically deleted. 


4. Reports and Statistics 


The various subsystems within the centrai processor 
are ail under the control of the Executive Control Subsystem 
(ECS). The ECS monitors the multi-programming environment 
and controls the exchange of information between subsystems 
and user programs. ECS includes functional areas involved 
with console control whereby the programming is affected by 
the computer operator; input/output control which allocates 
peripheral devices to programming modules and subsystens; 
program control which allocates the CPU to various 


subsystems ona priority basis; and interrupt control. The 


CPU is allccated in the following descending order: 
executive, highest communications I/o functions, 
communications processing functions and support. The 


Support Program Subsystem (SPS) supervises report generation 
and file maintenance. The dual nature of the files ailows 
updating to be accomplished off-line. Statistical analysis 


reports are generated daily summarizing key message 
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processing and traffic statistics 


Message files are maintained both on-line and 
off-line. A six months file of messages for retrieval 
purposes is stored on magnetic tape, while separate on-line 
files are designed to be kept for either ten or thirty days. 
The ten day file is on direct access storage and is utilized 
for broadcast channel reruns, broadcast screen, susdufe and 
service actions. The thirty day file is to support on-base 
users for readdressal, reference routing and redistrikution 


reguirements. 


C. MANPOWER REQUIREMENTS 


In accordanc=2 with the NTAP goal to reduce manpower 
levels, automated systems are to perform the routine message 
handling chores, thereby releasing personnel for more 
creative tasks in management and supervisory areas. Actual 
Manpower reductions are expected to vary from station to 
Station depending on the degree of automation and the volume 
and type of traffic. The design intent was to create a 
“user transparent" systen. For some operating positions 
this has -been accomplished, and personnel familiar with 
manual technigues can transition over to working competently 
with the automated system after a month or less of 
on-the-job training. Other positions require new skills, 
and personel assigned these jobs routinely need 
approximately three months of intenSive on-the-job training 
to acquire proficiency. Consequently, personnel familiar 
with manual techniques can be expected to transition over to 


operation of the automated system with minimal training. 


1. NAVCCMPARS Billets 


a a GTS ee ames wae SS eS ee SE 
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A NAVCOMPARS reguires the creation of 58 billets 
which are unigue to the operation of this automated systen. 
Of these new billets, 56 are identified for the Radioman 
(RM) rating and two are for Data Processing Technicians 
(DP). Experience at operational installations has 
demonstrated that the average radioman can handle computer 
operations; therefore, RMS are being asSigned to positions 
such as computer operator, router, OCR operator and Fleet 
Center command VDT operator. The billet for the 
Programmer/Systems Anaiyst is for a Chief Data Processing 
Technician, while a First Class Data Processing Technician 
fills the Assistant Programmer billet. AS part of their 
duties, the DPs will assist in the installation of 
Succeeding versions of the system and will update the 
current system in accordance with program changes fron 
NAVCOSSACT. Additionally, they are responsible for on-site 
software maintenance and problem documentation. A new Navy 
Enlisted Classification Code (NEC), DP-2746, has been 
established for LDMAX/NAVCOMPARS® programmer/systen analysts. 
Source ratings are DP and RM. The above billet requirements 
concern cnly those positions necessary for the NAYCCMPARS 
installation; many existing billets required for a manual 
system wiil be transferred unchanged to an automated one. 
Personnel will still be needed to fill administrative and 
Supervisory fositions such as communications watch officers 
and section supervisors. Since message reproduction and 
distribution has not been automated, these functions must 
still be performed manually. Despite the creation of new 
billets, substantial personnel savings can be realized with 
an automated system. Major reductions for a NAVCOMMSTA will 
occur in the Fleet Center and the Message Center. The 
largest saving in the Fleet Center is a result of NAVCCMPARS 
keying the fleet broadcast on-line. Eliminated are such 
jobs as broadcast operator, recap operator and broadcast 


traffic checker. Reductions have been made also in the 
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number of personnel required as torn tape operators for the 
broadcast and full period terminations. Cuts in the Message 
Center have cccurred through the elimination of manual 
Look-up of routing indicators, assignment Of OTC 


distribution and tape cutting operations. 


2. Statistics from 


AVCOMMSTA Norfolk 





A study of personnel requirements of NAVCCUMSTA 
Norfolx pefore and after installation of a NAVCOMPARS 
highlights the areas where personnel reductions are nost 
prominent. The following summary, taken from Reference 28, 
emphasizes the impact that automation has had on the Fleet 


Center and Message Center. 


BEFORE 


NAVCOMMSTA NORVA = NAVCOMPARS NAVCOMPARS INCR/DECR 
Management Group 007 009 ~02 
Watch Officers 008 008 

Fleet Center 041 097 or 
Computer Center 019 024 =i) 
Message Center 050 089 =3 9 
Service Center 012 012 

Data Base Maintenance 013 000 +13 
TOTAL 150 239 =89 


These above reductions were realized even though 
NAVCOMMSTA Norfoik had been automated previously to a 
limited degree. NAVCOMPARS replaced an Autodin IBM 360/20 
installation. As noted above, the total number of personnel 
needed for operation of the computer center decreased 


because the IBM 360/20 required extra operators to handle 
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Manual message entry and removal from terminal equipment. 
The NAVCOMPARS computer center is not involved in message 
input/output procedures. Since the opresent NAVCOMPARS 
installations are on maintenance contracts, requirements for 
Navy Maintenance personnel are also reduced; however, the 
cost of maintenance contracts yould negate any actual 
monetary savings. The above figures are representative only 
of NAVCCMMSTA Norfolk and can not be projected 
unconditicnally to the other NAVCOMPARS sites, but the 
potential for personnel reduction and improved nessage 
processing through automation clearly exists. The 
realization cf these personnei reductions requires the full 
support of the cognizant command. All too often, a command 
will not give up billets whose functions have been 
eliminated due to automation. Stations have used these 
released manrfower assets to augment shortages perceived in 
other areas; thus the only effect of communications 
automation has been the shift of personnel resources within 


a command, with no total manpower reduction resulting. 


3. tao thing 





One design objective of the LDMX/NAVCOMPARS systen 
was that additional schooling should not be required prior 
ee. assignaent of personnel to NAVCOMPARS sites. 
Consequently, the formal training program for NAVCOMPARS 
operating personnel is rather limited. No training course 
is taught at any military school, and the major 
responsibility iO T training has been inherited by 
NAVCOSSACT. NAVCOSSACT, assisted by JUnivac instructors, 


conducts four weeks of raining for computer 
programmers/systen analysts. On site training, also 
conducted by NAVCOSSACT and consisting of classroon 


presentations and on-the-job training, is concentrated ia 


the seven weeks prior to test and acceptance of a system at 
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each individual location. This 1S a one-time effort, and 
the indoctrination of subsequent replacements has been been 
left to the individuai command, although NAYCOMMSTA Norfolk 
is currently preparing video-tapes and programmed lessons 
for use as instructional material by all NAVCOMPARS sites. 
Experience at Norfolk has demonstated that individuals can 
become prcficient as routers and service clerks in four 
weeks and six weeks respectively. The training period for 
the Fleet Center Command VDT operator normally takes 
longer-about three months-because the major responsibilites 
such aS gueue status control and channel management are 
essentially new functions unrelated to any prior 
communications experience [{Ref. 26]. In order to gain the 
Maximum benefit from the training and experience that is 
developing among the personnel currently assigned to 
automated stations, the Bureau of Naval Personnel must adopt 
a policy of rotating experienced personnel from one 
automated site to another. This presently is not being 
done, and any Knowledge acquired from one tour is not being 
utilized in subseguent assignments. Additionally, the 
NAVCOMPARS sites are having to accept personnel with no 
background in automation and indoctrinate them with the 


basics before they can be used effectively. 
D. NAVCCMPARS/IXS INTERFACE 


The Satellite Information Exchange Subsystem (IXS) 
consists of three components: Common User Digital 
Information Exchange Subsystem (CUDIXS), Submarine Satellite 
Information Exchange Subsystem (SSiXS) and Tactical Data 
Information Exchange Subsystem (TADIXS). Programs for the 
development of the NAVCOMPARS system and the satellite 
Information Exchange Subsysten (IXS) originally proceeded 


concurrently but independently. One of the objectives of 
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CUDIXS is that it have an on-line connection into the 
Autodin network. With the successful impiementation of 
NAVCOMPARS, adherence to the principles of the NTAP dictated 
that NAVCOMPARS and cCUDIXS be interconnected, thereby 
eliminating software and hardware redundancy and reducing 
requirements for operating personnel. Currently, ae¢ither 
TADIXS nor SSIXS has the requirement for an on-line entry 
into Autodin; however, the procedures developed for the 
NAVCOMPARS/CUDIXS link could be utilized in the future with 
SoEAS. 


CUDIXS, a store and forward systen using a 
communications satellite to relay message traffic, is being 
implemented as an alternative to present high frequency 
Ship-shore-ship communications. The shore component is a 
Network Control Station {NECOS) which oFganizes its. 
Subscriber ships into a functional net. The NECOS, in 
conjunction with the satellite terminal equipment and the 
satellite, will provide teletype message capability toa 
group of sixty ships. Of this total, fifty will pe smaller 
ShipS waich will be equipped with shipboard terminais which 
Will allow them t0 transmit, but not receive, message 
traffic via sateliite on the CUDIXS channels. These ships 
Will receive all message traffic addressed to then by means 
of the fleet broadcast. The fleet broadcast uses a separate 
Satellite channel, and the transmissions will go directly 
from NAVCOMPARS to the satellite terminal equipment. (See 
Figure 2). The remaining ten ships, designated "Special 
Subscribers," are high volume users which will have both the 
send and receive capability. (See Figure 3). Employing 


round-robin network discipline to maintain control of its 
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net of ships. The shore station sends out a subscriber 
transmission sequence which specifies the order in which 
subscribers are to transmit. Each scheduled network cycle 
includes a transmission phase and a reception phase to/from 
each active subscriber. The NECOS will check the status of 
each subscriber to transmit or receive messages prior to 
each operating cycle; by means of intercept processing, it 


can hold traffic until a subscriber is capable of receiving. 


The CUDIXS shore equipment, designated 
AN/USQ-64(V)2, is located in the NAYCOMMSTA Fleet Center and 
utilizes the AN-UYK-20 mini-computer to accomplish its 
functions. NECOS will gueue traffic for transmission by 
message precedence, automatically synchronize modulation and 
cryptographic equipment for transmission and perform all 
data transfers on the satellite link. After transmission is 
ccmpleted, the shore station will coordinate the passing of 
the proper acknawledgements. Several short messages may be 
forwarded to a ship during one transmission cycle, cr one 
long message may require several cycles for completion. 
Untransmitted message portions are stored in the buffers of 
the NECCS until the next cycle. 


2. Systems Interrace 


_—qeae 


The linking of these two systems will allow cCUDIXS 
subscribers to have access to those functions which 
NAVCOMPARS currently provides to OTC, broadcast and 
dedicatedyfull period users, such as format validation and 
correction, utilization of modified ACP 126 format and 
direct on-line access to two different ASCs. Equipment and 
Operator savings will be realized in that the NECOS does not 
need to maintain a separate Mode I terminal for entry into 
Autodin. A more direct altroute capability exists because 


NAVCOMPARS can reroute messages automatically from a poor 
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quality satellite tink to a breadcast or full period 
channel. CUDIXS subscribers will be able to recall messages 
from NAVCCMPARS files for up to ten days on-line and six 
months via magnetic tape. NAVCOMPARS will maintain a 
subscriber message number (SMN) directory which wili 
accomodate a 24-hour file of messages transmitted to each 
subscriber. This file allows subscribers to request message 
reruns uSing the SMN as a reference. Utilization of the 
file capacity of NAVCOMPARS eliminates the requirement for 
separate message storage by the NECOS, thereby generating 
further equipment savings. NAVCOMPARS prepares the 
necessary statistics and reports for both systems. The 
NECOS will ccntroi ali data transmission via the satellite 
link, and the interconnect between the two systems will not 
impose any additional timing restrictions on the NECOS. A 
CUDIXS shore station has been installed at NAVCOMMSTA 
Norfolk, but it is still undergoing testing and evaluation. 
The interface between NAVCOMPARS and CUDIXS has functioned 
Satisfactorily, but problems have been encountered in the 


Shipboard terminal. {Rer. 28] 


a. Shore-Ship Message Flow 


A message routed to a CUDIXS “Special 
Subscriber" could enter the NAVCOMPARS from any source. 
After internal processing by the NAVCOMPARS, the message, 
preceded by a header identifying the subscribers who are to 
receive tne message, iS queued by precedence to CUDIXS. 
Upon successful delivery or the message to all addees, the 
NECOS will return a control record to the NAVCOMPARS which 
identifies the subscriber's SMN, and the NAVCOMPARS will 


journal the message. 
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b. Snip-Shore Message Flow 


Modified ACP 126 narrative messages are to be 
transmitted from subscribers to the NECOS, where the traffic 
1s gueued by precedence to the NAVCOMPARS. After the EOM 
indicator nas been accepted by the NAVCOMPARS, the NECOS 
will generate a one line acknowledgement message to the 
subscriber. The NAVCOMPARS will validate/correct the 


message and route the message as appropriate. 


E. DATA BASE HAINTENANCE 


The NAVCOMPARS data base is composed of the library 
file of processed messages, the local station internal 
distribution files and those files used to route messages. 
Due to the staggered installation dates of the various 
NAVCOMPARS sites, each location waS initially responsible 
for development and maintenance of its data base. Of 
primary coacern in the development of the data base was the 
accuracy of the routing files, and this section will discuss 
Oniy this particular aspect of the WNAVCOMPARS data base. 


Le Historv of the Common Source Routing File 
C= eae <== a eee Sas a 
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One of the key characteristics of NAVCOMPARS aS a 
tactical communications system was that it would possess the 
capability to provide routing instructions for all traffic 
ofiginated by shins, thereby alleviating individual ships of 
the continuing task of maintaining an updated edition of 
ACP-117, the world-wide routing indicator (RI) list. Due to 


the = tiie compliance with the requirement for 
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standardization of hardware and software at all NAVCOMPARS 
Sites, the capability existed for the various NAVCCMPARS 
to assume traffic handling functions for each other during 
periods of downtime; however, for this procedure to work 
effectively, the previously individualized data bases also 
needed to be standardized. Initial responsibility for data 
base maintenaace was assigned to NAVCOMMSTA Norfolk, and 
this station began to update the data bases of all 
NAVCOMPARS sites in September 1974 by means of a Common 
Source Routing File (CSRF). Ali routing indicator changes 
were transmitted to Norfolk, and that station prepared the 
necessary ccmputer inputs to make the required additions and 
deletions. These inputs were then forwarded via card 
traffic on a daily basis to all other NAVCOMPARS Stations 
for file update action. Since June 1975, NAVCCMMSTA 
Honolulu has acted as the CSRF Update Facility for the 
Western Hemisphere, and Norfolk has retained responsibility 
for the Atlantic and Mediterranean areas. Norfolk and 
Honolulu’ receive identical update information with which 
they unilaterally prepare the input for the CSRF. Prior to 
further dispersal of this information, the above stations 
compare their data via point-to-voint orderwire, and any 
conflicts are researched and immediately resolved. After 
ali necessary corrections have been made, the daily update 
information is forwarded to the other CSRF subscribers. The 
actual udating of the CSRF is done on the off-line file 
system, and the complete procedure takes approximately four 
hours; the new files go on-line at 0001Z of every new radio 
day. On-line VDT changes can be made for immediate ufdate, 
and an average of five of this type are accomplished each 


day. . 


NAVCOMMSTA Norfolk has thirteen billets authorized 
for data base Maintenance, and NAVCOMMSTA Honolulu 
operates its CSRF facility with approximately the sane 


number. Not only does this procedure ensure a world-wide 
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Standard routing file, but it also saves manpower resources 
because the above two stations are managing this vital 
function for the whole network. These savings will be 
increasingly significant as additional LDMX stations are 
outfitted with NAVCOMPARS software and become part of tke 
CSRL « 


2» omposition of Commo 


Source Routing File 


The CSRF has five component parts: ACP Routing 
Indicator File, Ships/Station Guard Source File, Task and 
Type Organization File, Multiple Address Routing Source File 
and the Alternate Spelling Source File. The ACP Routing 
Indicator File contains the preferred spelling of a 
command's short titie as specified in NTP-3 and up to four 
RIS which can be used for delivery via electrical means. 
This file, which is basically the information contained in 
ACP-i117, is continually updated via card input of additions 
and deletions. As of September 1975, there were more than 
21,900 entries in the ACP file. The Ship/Station Guard 
Source Fiie contains a list of commands or units by short 
title which are guarded for by a host ship or station. In 
this way an embarked commander is related to his host ship 
for broadcast screening action. The composition of Navy 
task and type force organizations are delineated in the Task 
and Type Organization File. Task force designations may be 
used to address singie or multiple addressees. That 1s, any 
task force, group, unit or element commander may be 
individually addressed, but a message addressed to a task 
organization wWili be automatically delivered to ali 
components of the specified organization. The Multiple 
Addressee Routing Source File is composed of every Navy and 
Coast Guard collective and Address Indicating Group (AIG), 
as well as many collectives and AIGsS of the other services. 


The only file prepared by the individuai stations is the 
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Alternative Spelling Source file. This consists of conmon 
abbreviations or misspellings of primary short titles in the 
ACP file, and its function is to relate the misspelled short 
title te the correct routing indicator. The last four files 
are maintained on magnetic tape with the daily update being 
accomplished via card changes being processed simultaneously 
With the running of the old tape to produce an entirely new 
tape. 
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The main difficulties encountered by NAVCCMMSTA 
Honolulu in managing the CSRF are in obtaining timely and 
accurate change information from applicable commands. 
Improper submission of data has resulted in confusion in 
Maintaining a complete Task and Type Organization File. 
Lower eschelon commands have requested that they be added or 
removed from an organization listing Without proper 
authorization from the cognizant commander. The Situation 
has beit the CSRY facility with the burden of resolving the 
conflicting data in order that its files will be accurate. 
NAVCOMMSTA Honoluiu has engaged the support of CINCPACFLT 
in this matter, and two messages addressed to all pacific 
fleet commands have been issued which specify that the task 
or type trorce commander has the responsibility to provide 
the CSRF facility with the breakdown of its components. Any 
contradictory information will be referred back to the 


applicable ccmmander for resolution. [{Ref. 22] 


Another problem involves the necessity for periodic 
and complete validation of the composition of coilectives 
and AIGs. Disestablished commands are still carried in 
certain AIGS and collectives siaply because the cognizant 
authority nas neglected to remove the outdated information. 


The CSRF facility can not cancel an AIG or delete data, even 
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1f it xnows such information 1S erroneous. The cognizant 
authority must do its job responsibly in purging the systen 


of extraneous and incorrect information. 


One minor provlem area at present which could cause 
major difficulties in the future is the inclusion of other 
service short titles in the NAVCOMPARS data base. Arny 
and Air Force AIGs and collectives with even one Navy, 
Marine Corps or Ccast Guard addee must be included in their 
entirety. The Navy has expended a great amount of effort in 
the past several years in order to standardize short titles 
in preparation for comaunications automation. The Arny and 
Air Force have done little to document and distribute 
preferred short titles for their commands; conseguently, the 
individual ccmmand may itself use several alternate 
speliings for its command designator. Any variation in short 
title which is not anticipated with an entry in the 
Aiternate Spelling Source File will require manual 
intervention, thereby negating a major portion of the 
advantage of automation. Unless the initiative is taken by 
the Army and Air Force to develop standardized short titles, 
extending $NAVCOMPARS capabilities to other military users 


could result in degradation of the system. 
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The section on traffic flow pattern of the NAVCOMPARS 
in the previous chapter described the functions of the 
NAVCOMPARS subsystems in general terms; this chapter will 
emphasize those major program modules within each subsysten 
which most directly affect message processing. Modules 
which direct error routines or handle special situations 
are, for the most part, neglected in order to give a 
comprehensive and straightforward description of routine 
message processing. The individual user retains a 
substantial amount of control over systen performance 
through his compliance, or lack thereof, with prescribed 
format requirements. The objective of this chapter is to 
create a model of the message processing sequence within the 
NAVCOMPARS CPU in sufficient detail to establish an 
awareness of and an appreciation for the format precision 
which is necessary for an automated system to operate at its 
full potential. 


The means utilized by this thesis to accomplish the 
above objective will be to follow a typical message through 
the NAVCOMPARS; a flowchart model with narrative comments 
Will trace the progress of one message through the message 
processing sequence. In order to demonstrate the full 
tactical potential of the system, the following scenario has 
been selected: A ship at sea transmits a routine message in 
modified ACP 126 format via HF radio to the nearest 
NAVCOMMSTA for entry into aAutodin and forwarding to a 
command in the Washington D. C. area. {Step 1, Figure 6] 
Figure 4 presents the sample message, and Figure 5 explains 


the function and structure of each format line. 
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BAL) 1 VZCZCABC127 
PY 2 RTTUZYUW RUEBABC#@34 3591719--RUHPSUU. 
E/7L 3 
P/L 4 ZNR UUUUU 
F/L S R161718Z DEC 75 
F/L 6 FM USS NEVERSAIL 
F/L 7 TO CHNAVPERS WASHINGTON DC 
F/L 8 INFO CINCLANTFLT NORFOLK VA 
F/L 9 
F/L 10 
F/L 11 BT 
F/L 12 UNCLAS 
TEXT 
Rye 13 BT 
F/L 14 
F/L 15 #2934 
nL, 16 NNNN 


Figure 4 - SAMPLE MODIFIED ACP 126 MESSAGE 
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FORMAT LINE 


F/L 


Fw/E 


F/L 


F/L 


F/L 


PYL, 
F/L 
F/L 
F/L 
F/L 
F/L 
F/L 
F/L 
F/L 
F/L 
F/L 


i: 


2 


Oo On DH 


ELEMENTS EXPLANATION OF SAMPLE MESSAGE CHARACTERS 
Handling instructions V-Ensures subsequent intelligence 
not garbled 
ZCZC-Start of message indicator 
ABC-Station/channel designator (CID) 
127-Channel sequence number (CSN) 


Header R-Precedence: ROUTINE 
TT-Language and Media Format (LMF): 
TELETYPE 


U-Classification: UNCLASSIFIED 
ZYUW- Communication Action Identifier 
(CAI): THIS IS A NARRATIVE MESSAGE 
RUEBABC-Originating Station Routing Indicator 
(OSRI) 
@934-Station serial number (SSN) 
359-Julian date 
1719-Time of file (TOF) 
UUUU-Classification redundancy 
RUHPSUU-Destination routing indicator: SPECIAL 
NAVCOMPARS RI ENDING IN SUU 
Period-End of routing symbol 
Calling Station 


and filing time NOT USED 

Transmission ZNR-Security prosign 

Instructions UUUUU-Classification designation: 
UNCLASSIFIED 

Precedence R-Precedence: ROUTINE 

& DTG 161719Z DEC 75-Date time group (DTG) 

Originator USS NEVERSAIL 

Action Addressee CHNAVPERS 

Information Addressee CINCLANTFLT 

Exempted Addressee NOT USED 

Accounting Information NOT USED 

Separation BT-Separates heading from text 

Text UNCLAS=-Classification 

Separation BT-Separates text from end of message 


NOT USED IN TAPE RELAY PROCEDURES 

EOM Validation #2934-Station serial number 

EOM Function NNNN=-Proceeded by 2 carriage returns and 
eight line feeds 


Figure 5 - EXPLANATION OF MODIFIED ACP 126 FORMAT 
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Be  ILNITELAL EROCESSING 


Upon receipt by the NAVCOMMSTA Fleet Center, the 
Message is visually screened by operating personnel to 
ensure that the message is of sufficient quality (no garbles 
in heading o¢ text) for entry inta the NAVCOMPARS. [Step 2, 
Figure 6] The paper tape copy is then manually run through a 
paper tape reader which introduces the message directly into 
the system. {Step 3, Figure 6] The Communications Control 
Subsystem (CCS) is a software package which provides the 
necessary support functions to coordinate the systen's 
peripheral equipment to the message processing subsystens. 
In this specific instance, CCS allows the paper tape reader 
to generate input to the Receive Control Subsystem so that 
the sample message is queued for the Receive Control Format 
Exchange Module (RCPX). [Step 4, Figure 6] 


Control Format Exchange Module (RCFX) 





The primary functions of RCFX are to convert the 
Narrative character codes of the various message input 
devices into a common character code and then to divide the 
input stream into proper length file segments for reccrding 
on the recovery disks. For the sample message, the 
five-level baudot code used by the paper tape reader is 
translated into EBCDIC to facilitate processing within the 
CPU. The shift characters of the teletype are set to null 
characters, and carriage returns and line feeds are deleted. 
REX identifies format lines 1, 2, 11, 13, 15 and 16 of 
every message. Line analysis is accomplished by a series of 
subroutines, each of which anaiyzes a specific line. Entry 


to the appropriate subroutine is gained by using an 
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Figure 6 - MESSAGE INPUT AND INITIAL PROCESSING 
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index to an address table of all line analysis subroutines. 
For this message, the index is set to format line one; as 
each format line is identified, the index is set to the next 
line analysis processor, but the index will not be bumrfed to 
the next subroutine until the line currently being sought is 
found. If format line two is not validated, the message is 
rejected, and a rejection notice is built. The format of 
the sample message is assumed to be validated as correct, 
and the amessage is assembled into file segments for the 
Recovery Disk (RCDSK). RCFX begins the process of building 
a Summary Data Area (SDA) for each message. As each format 
line 1s identified, applicable information such as the 
CDCSN, precedence code, input device symbol, OSRI, SSN, and 
mumerics of straggler check are transferred to the SDA. 
[Step 5, Figure 6] 


2. gseceive Control Input/Output Module {RCTO) 


The function of RCIO is to accomplish the dual 
recerding of message informaticn on the Recovery Disks 
(RCDSK) which are resident on on-line magnetic disk facks. 
The information recorded On each RCDSK consists of certain 
line defining information, actual material from the message, 
data linking instructions and sone message handling 
information. The inputs to RCIO include the message 
segments and SDA generated in RCFX, and processing of this 
information falls in three categories: start, middle and 
end of message. Start of message processing is designed to 
initiate the disk address linkages for the entire message 
perce te “the Writingrrot the YRCDSK. Middle processing 
handles continuation linkages for the message and then 
writes the message on both Recovery Disks. End of message 
processing incorporates the SDA into the final section anc 


adds finalization linkages as necessary. [Step 6, Figure 6} 
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Deaeetesonok LFROCESSING SUBSYSTEM 


The RCS/MPS Interface Table iS core~-resident in the 
Common Data Area, and it iS used as a means of communication 
between the two subsystems. After the RCDSKsS have been 
written and RCS haS a message gueue entry to pass to MPS, 
RCS will place the RCDSK pointer, message type and message 
priority in the interface table and will set an indicator 
requesting transfer to MPS. {Step 7, Figure 7] MPS 
periodically checks the indicator, and when it is set, MPS 
will enter the message in its input queue and set an 
acknowledgement indicator for RCS in the interface table as 
to the action taken. Processing for the sample message 


begins with the Common JANAP 128 Heading Analysis Ncdule. 


1. Common JANAP 128 Heading Analysis Module (MPJA) 


> Sa ae ce ae SS ee ee ie ae ew eae ae SS SSS See ee 


MPJA operates on non-data pattern JANAP 128 and 
modified ACP 126 messages with its major function being the 
analysis cf the heading up to and including format line 
five. The processing includes format line analysis, routing 
indicator isclation, end-of-message checks and straggler 
checks. A straggler is a message which, because of an 
incorrect end-of-message function, either trails or is 
attached to the preceding message. Throughout the 
identification process, all vital elements of information 
are preserved in the MPS SDA for subsequent processing. The 
MPS SDA 1s a core resident buffer which provides an area 
where prccessing programs can maintain and obtain transient 
data (such as line counts) or provide pertinent data (such 
as the station serial number assigned by MPJA) to fulfill 
other program's tasks; it is used by all modules in the MPS 
environment, with each module updating specific fields as 


the message frocesSing analysis functions are perforned. 
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Figure 7 - MESSAGE PROCESSING SEQUENCE 
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MPGA begins procesSing analysis by fetching the first line 
of a message segment and testing it for format line one; if 
validated, this line is transferred to the SDA. Processing 
then continues as MPJA fetches the next line and validates 
it element by element. Format line two elements are 


interrogated in the following order: 


a. Precedence character 

b. Language and Media Format 

c. Classification (The Seca ey level is Sense 
saved for redundant security test with the security field in 
columns 30-33.) 


» Gee Channel Identification Code/Command Action 
Identifier 


Ye eng Station Routing Indicator and Station 
Serial Number (Used for straggler check with F/L 15) 


£. Time cf Pile 


oe Security Field (This field must agree with the 
security character saved from column 4.) 


h. Test for modified ACP 126 type nessage ie Ri in 
the format line is compared for the special NAVCOMMSTA RI 
ending in SUU.) 


1. Pericd 


If any element is unable to be validated, a display is 
built ror the VDT operator indicating the error. The screen 
Will be annotated with an error notation reading “INVALID 
P/L X" which will be followed by ten addditional lines of 
the message. The VDT router can either correct the line or 
reject the message to either the Service Clerk or the Top 
Secret Courier. Since the sample message is correctly 
formated, each element is validated and then stored in the 
SDA. 


MPJA continues to fatch each line in turn, validating 
it depending on the characteristic of that particular format 
line. The sample message has no format line three; 
therefore, it will next encounter the security prosign 
(either "ZNR" or "ZNY") in format line four. "ZNR" is used 


with unclassified messacses, while "ZNY" is used with all 
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classified messages including those designated UNCLAS EFTO 
{Encrypted fcr Transmission Only). After validating the 
prosign, MPJA will next access the security redundancy 
symbols. Since the sample message has the prosign "ZNR", 
the only acceptable designation is the characters "JUUUU" 
representing an unclassified message. Having validated this 
as correct, the routine compares format line four security 
to that found in format line two; if these don't agree, a 
mismatch has occurred, and a display is built fer the 
router, who can either correct the line or reject the 
message. In scanning format line four, MPJA also searches 
for precedence, and it enters format line five processing 
when it finds arguments which neet these search criteria. 
In all cases where a dual precedence exists, ‘format line 
five will be validated if the format line two precedence 
matches either the ACTION or INFO character. MPJA then 
searches for the date-time-group, and, when found, the 
module moves the entire line to the proper field in the MPS 
SDA in order to effect the Originator Date~time-group File 
update. If the DIG can not be delimited, MPJA causes a 
display of the message to the router who can assign or 
correct the ODTG or reject the message to the service clerk. 
Once the entire line has been processed, it is moved to the 
SDA. In addition to format line validation, MPJA performs a 
check for Suspected Duplicate (SUSDUPE) messages. The 
arguments ror the OSRI SSN search are extracted from the 
proper fields in the SDA and are used for comparison against 
the system's Originating Station Routing Indicator file. If 
the message is a SUSDUPE, it is rejected to the service 
clerk and further processing is terminated. The processing 
serial numbers of up to seven previous duplicates are 
extracted frem the file and are appended as a service line 
in order to facilitate action by the service clerk. MPJA 
waives the SUSDUPE check for all Flash and Emergency Command 
messages. Once format line five has been entirely 


validated, MEJA has completed its processing on modified ACP 
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Wo type messages, and it relinquishes control. [Step 8, 
Figure 7] The next module is MPFC. 


2. Message Processing Subsystem ACP 126 Routing and 


SE ai SS GS Se Ge eee Ge 


MPJA has up to this point constructed a model of 
certain perticns of the JANAP 128 header; MPFC continues 
format line analysis with line six and completes the 
conversion frem modified ACP 126 to JANAP 128 format. mt 
also does faging, sectioning and maintenance of continuity 
for sectioned nessages. Errors and illogical conditions 
that arise during processing are referred to a VDT operator 
for resoluticn. The rRCDSK segment which contains format 
line six will already be core resident, but MPFC will access 
RCDSK aS many times as necessary to read all segments 
associated with the message. [Step 9, Figure 7} This module 
begins precesSing by reading the first three characters of 
the line and testing them for the argument "FM". If this 
configuration is not identified, MPFC causes a display to 
the router who can correct the line. If the first three 
characters are correct, MPPC accesses the short title and 


validates it. 


The message header is then scanned fcr one of the 
following arguments which are positional: "TO" or "INFO". 
When neither is found, an error is diagnosed and a display 
eee built sforethe couter. Tf "T0" is found, MPFC goes into 
format line seven processing in order to validate short 
titles and assign routing indicators. The routine will 
determine if a short title is valid by comparing it with the 
information in the Routing File Directory (ROUTFL), which is 
a consolidation of all the on-line message processing files. 
If a short title can't be found in the ROUTFL, a display 
will be built for the router indicating this fact. When the 


Be 
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short title is validated, the routine then proceeds to 
determine the routing indicator. The ROUTFL itself will 
contain one primary RI. If the RI thus obtained is not 
cleared for the classification of the message or if a 
collective routing is indicated, the processing routine will 
extract a pointer from the ROUTFL for the ACPFIL entry for 
that short title and the necessary routing indicator will be 
accessed from that entry. {Step 10, Figure 7] 


Once the format line seven processing has been 
accomplished, MPFC initiates a program scan for the next 
processing event. If "INFO" is encountered, the routine 
utilizes format line eight processing which is identical to 
F/L 7. When "XMT" is detected, MPFC takes action to remove 
the exempted addressee from any collective rcuting 
indicators. The sample nessage has no format line ten, so 
the next event validated py M?FC will be the "BI" in format 
line eleven. After the "BT" has been framed and moved, the 
programming module begins text processing with format line 
twelve. MPFC will examine the security narrative in this 
line and will determine if it matches the security warning 
found in both format lines two and four. If the security 
narrative does not agree, a mismatch has occurred, and MPFC 
Will build a display to the router for the resolution of 
-this error condition. Any special handling instructions are 
identified and validated. After the security and special 
handling criteria have been processed, MPFC tests the 
message line count to determine if this will be a sectioned 
message. Messages are sectioned only if they exceed five 
pages or 100 lines of text from format line twelve. In 
order to ascertain the number of sections for long messages 
which meet the above criteria, MPFC substracts the numker of 
lines found from F/L 2 to F/L 11 from the total message line 
count. The result is divided by twenty to determine the 
number of pages; this figure is then divided by five to 


arrive at the number of sections. 
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Dieting text processing, reference lines and 
paragraph lines are searched for and identified for any 
hecessary subsequent processing. After the textual pcrtion 
of the message has been processed, MPFC completes the JANAP 
128 header in the SDA by attaching the routing indicators 
for format line two. MPFC sorts these indicators in binary 
ascending order and then moves them to the MPS SDa. 
Duplicate RIS are not moved and are thus eliminated fron 
inclusion in the header. After the header and routing 
information have been supplied and all necessary linkages 
between text segments and these elements have been effected, 
the message is redundantly written on the Message Processing 
Disk (MPDISK); the data contained on this disk is the output 
image of the message. [Step 11, Figure 7] MPFC then causes 
the message to be queued to the Transmission Processing 
Subsystem (TPS), thus completing an input transaction. 
{Step 12, Figure 10] Figure 8 is the output version of the 
sample message in JANAP 128 format. Pertinent 
characteristics of this format have been explained in Figure 
DF. 


C. TRANSMISSION PROCESSING 


The remaining NAVCOMPARS subsystems handle the message 
transmission and journaling functions. The modules cf the 
Transmission Processing Subsystem (TPS) deal with the 
message queuing functions, while the modules of the 
Transmission Control Subsystem (TCS) supervise channel 
activation and message delivery. As the sample nessage will 
be relayed to its ultimate destination via the Autodin 
system, the Autodin Control Subsystem (ACS) is the final 


subsystem thru which the message must traverse. 
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Figure 8 - SAMPLE OF JANAP 128 MESSAGE 
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ELEMENTS EXPLANATION OF SAMPLE MESSAGE CHARACTERS 
Handling Instructions V-Ensures subsequent intelligence 
not garbled 
2CZC-Start of message indicator 
XYZ-Station/channel designator (CID) 
@66-Channel sequence number of NAVCOMMSTA 
Header R-Precedence: ROUTINE 
TT-Language and Media Format: TELETYPE 
(Repeats LMF of original modified 
ACP 126 message) 
U-Classification: UNCLASSIFIED 
ZYUW-Communication Action Identifier: 
THIS IS A NARRATIVE MESSAGE 
RUHRSVC-Crigination Station Routing Indicator: 
ROUTING INDICATOR FOR THE NAVCOMMSTA 
SERVICE CENTER £S USED AS THE CUTGOING 
RI ON NAVCOMPARS MESSAGES 
$321-Station Serial Number: SUPPLIED BY 
NAVCOMPARS 
359-Julian date 
171%@-Time of file 
UUUU-Classification redundancy 
RUWMFDA-Destination routing indicator 
RUCLBEA-Destination routing indicator 
Period-End of routing symbol 


NOT USED 

Transmission ZNR-Security prosign 

Instructions UUUUU-Classification designation: 
UNCLASSIFIED 

Precedence R-Precedence: ROUTINE 

& DTG 161719Z DEC 75-Date time group 

Originator USS NEVERSAIL 

Destination RI RUWMFDA/CHNAVPERS 

& Action Addressee 

Destination RI RUCLBEA/CINCLANTFLT 

& Information Addressee 

Exempted Addressee NOT USED 

Accounting Information NOT USED 

Separation BT-Separates heading from text 

Text UNCLAS-Classification 

Separation BT-Separates text from end of message 
NOT GSED 

EOM Validation #08321-NAVCOMPARS Station serial number 

EOM Function NNNN=-Proceeded by 2 carriage returns and 


eight line feeds 


Figure 9 ~ EXPLANATION OF JANAP 128 FORMAT 
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Once the message has been processed by ACS, the sample 
message has ccmpleted the NAVCOMPARS cycle. 


When the sample message comes under tke responsitility 
of TPS, the initial module which assumes control is the 


Transmissicn Processing Queue Handler. 


1. Iransmission Processing Queue Handler (TPQH) 


aS Se —_—aeS ee ey ae 


TPQH 1s the module which manages all gueuing 
functions, as well as other related tasks such as checking 
for message/line security mismatches and the generation of 
queuing statistics. In order to fully understand the 
procedures utilized by TPQH, several terns must be 
identified and defined. A bit map is included in the SDA 
for each message; the intended destinations of each message 
are indicated by whether predetermined bits are placed in an 
Yon" condition. Initially, two maps are created. fhe 
original remains intact, but the duplicate is modified and 
updated as e€ach individual delivery is made. Files labelled 
Destination Ccntrol Blocks (DCB) are maintained in core 
memory fcr eéach outgoing channel and electronic ccurier 
Gi@ecuit. (POH 1s structured to utilize two separate quwedges 
for each message. A mesSage queue, designated Q1, contains 
an entry for each individual message processed by the 
systen. The information contained in the Q1 entry includes 
the following: a transmission count giving the number of 
destinations for the message, a pointer to the location of 
the message on the RCDSK, a pointer to the location of the 
message on the MPDISK, the code for message type, and the 
processing priority assigned to the message. A pointer is a 
link between one record and another in that a field in the 
first record indicates the location on the storage devices 
of the seccnd record. The other queue is the transmission 


queue, knewn as Q2, which functions as a storage area 
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for pointers to message entries in Q1. Each Q1 entry has 
corresponding Q2 entries for each Destinaticn Control Block 
to be utilized to effect delivery. The information included 
in each Q2 entry consists of a pointer referencing the 
relative position of the applicable Q1 entry and a pointer 
linking the Q2 entry to the next Q2 entry for this 
particular DCB. Within Q2, all entries for a particular DCB 


are linked together by processing precedence. 


The sequence of events involving the above 
components is begun when message information from MPS is 
engqueued to Q@1 and a Q1 entry is created. [Step 13, Figure 
10] The bit mavs of this message are examined to deternine 
all the destinations. Once a destination is identified, 
TPQH will match the security classification of the message 
against that of the destination channel. If a mismatch has 
occurred, the message will be diverted to the Top Secret 
courier and a service message delineating the error will be 
created. [Step 14, Figure 10] Otherwise, Q2 pointers and Q2 
entries will be created, and the 92 entry will be linked to 
the appropriate DCB. [Step 15, Figure 10] When the message 
reaches the head of the queue, the Q2 pointer will be used 
to access the Q2 entry, which in turn provides the Q1 
pointer to access tne Q1 entry. Tne Q1 entry then leads 
back to the output image of the message on the MPDISK, and 
this is read for transmission. After transmission 
acknowledgement, the Q2 entry is dequeved. Subsequent to 


message journalization, the Q1 entry is dequeued. 


Other functions performed by TPQH are involved with 
overall queue management and recording of statistics. The 
module maintains queuing counts by precedence for each 
destination channel or courier circuit, and it will notify 
the Fleet Center VDT operator by means of a service notice 


whenever pre-established thresholds are exceeded. 
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Additionally, TPQH totals queue statistics for each radio 
day. 


2. Ifans@ission Control Line Program (TCLP) 


TCLP is a module of the Transmission Control 
Subsystem, and its main functions are to monitor the status 
of individual channels and to begin message transmission 
when channels are activated. MTCLP will access the 5DCB to 
receive the next queue entry from TPQH. Another check will 
be run by TCLP to validate that the line security level is 
equal tc or greater than the message classification. 
Messages wiil be rejected to the Top Secret courier if this 
test is failed. Upon completion of delivery, TCLP will 
instruct TPS of this fact and will provide the applicable 
channel sequence number. 


Because the sample message will be entered into the 
Autodin network, additional processing steps are required. 
Determination must be made as to which Autodin Switching 
Center will receive the message; the message will be sent to 
the primary switch if it is available and otherwise to the 
secondary switch. fhe primary switch is the one designated 
to handle che greater number of routing indicators. MfCLP 
Will access the MEDISK to obtain the message data for 
transmission, but any previously recorded format line one 
Will be deleted. The programming routine adds the necessary 
upshifts, downshifts, carriage returns and line feeds, and 
then converts the message into ASCII code for the outgoing 
Autodin line. The mesSage data is then placed in the 
Autodin Transmit buffer for transfer to the Autodin Control 


Subsystem. [Step 16, Figure 10] - 
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Ss Amcodin Control Module (ACS) 
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This module links the Series 70/45 processor to the 
two 70/1600 Autodin terminals, one far each Autodin 
Switching Center. TCS will notify ACS when an outgoing 
message has been stored in the Autodin Transmit buffer, and 
ACS wilil retreive the message segments and transmit them to 
the appropriately designated 1600 processor. ACS receives 
acknowledgement of message receipt from the 1600 processor 
and passes this acknowledgement back to _ TCS. {Step 17, 


Figure 11] 
-  d£Lansmission Processing Message Journal Module 
{TEMJ) 


TEMJ accomplisnes the journal entries for every 
message that is processed by NAVCOMPARS. All messages are 
written on the Journal Tape File; this file is stored on 
Magnetic tape, and each message 1s kept for six months. 
Additionally, a journal file of all over-the-counter traffic 
is maintained on disk for apptoxinately thirty days. TPHJ 
does journalizing action on a timed interval of every three 
Minutes or whenever ten messages are waiting in the journal 


queue. [Step 18, Figure 11] 
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Ve. CONCLUSION 


a See aS 


This thesis has delineated the major procedures involved 
in processing messages traffic, as well as examined various 
related system aspects such as training and data hbase 
management. The emphasis of this paper has focused on 
providing a basic understanding of NAVCOMPARS and its 
associated frocedures as they exist today. The intent was 
to produce a document which could be used as an orientation 
text for personnel upon initial contact with an automated 


communications systen. 


The manager in a communications environment must be 
involved with the total system-with both human and non-human 
elements. Because NAVCOMPARS is currently operational, 
the equipment and the prescribed message procedures are 
fixed in the short-run. Therefore, immediate improvements 
in message handling efficiency can only be obtained by 


gaining the support and dedicaticn of the personnel 


utilizing the system and stimulating them to better 
performance. In the long run, equipment and procedures can 
be modified in an effort to upgrade the systen. The 


concluding section of this thesis will discuss some 
background which affected system development and will 
present projected modifications of NAVCOMPARS. 


A. HARDWARE 


The heart of NAVCOMPARS is the UNIVAC Series 70/45 
{formerly RCS Spectra 70/45) central processing unit. This 
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computer was procured through competitive formally 
advertised procedures and was selected as the CPU which met 
the technical specifications and which was most cost 
effective. [Ref. 24] RCA brought out the Spectra 70 series 
of computers at the end of 1964 as a competitor to the newly 
introduced IBM 360 family. Even though the Spectra 70s were 
estimated to be priced at 40% of the cost of the comparable 
I5BM 360s, they did not make a significant impact on IBM's 
market. In 1970 the RCA computer division chief 
re-introduced the Spectra 70 series and cut prices further 
to attract business. As a result of inefficient management 
within its computer division, RCA left the computer industry 
in 1971 and sold its base of customers to the UNIVAC 
division of Sperry Rand. [Ref. 3] Since 1 January 1972 the 
Navy has received service on its Series 70/45s from UNIVAC. 
The NAVCOMPARS/LDMX computer equipment was leased up until 
August 1975 when the decision was made to buy the existing 
installations. [Ref. 21] Difficulty has been encountered in 
that the Series 70/45 has reached the limit cf core memory 
that the systen can handle. The original core memory 
consisted of 252,14% (8 bit) bytes. [{Ref. 28] This capacity 
has been doubled through the addition of boxes of core 
RemOry. The implementation of additional functions on the 
NAVCOMPARS will have to be delayed pending the acquisition 
of the follow-on CPU with its expanded core memory. The 
decision has been reached to procure the UNIVAC 90/60 as the 
foliow-cn to the Series 70/45. The 90/60 system will have a 
Maximum of 1,088,000 pytes of core memory and will be able 
tc support planned systen enhancements such as the 
consolidation cf special intelligence and general service 
traffic within a single processor. The 90/60 processor will 
be installed at NAVCOMPARS sites, while the Navy-owned 
70745s will be split apart and used to back fit fprojected 
LDMX locations. As an LDMX utilizes only one CPU, each 
upgraded NAVCOMPARS can provide a 70/45 for two LMDX sites. 
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Another hardware problem has revolved around the 
peripherial equipment utilized for file storage. The 
original equipment configuration included a Mass Storage 
Unit which recorded data on magnetic cards and could contain 
up to 45 days worth of message traffic. This unit proved to 
be mechanically unreliable, and its access tine was 
relatively slow. In order to alleviate these conditions, 
the Mass Storage Units are being replaced by a Direct Access 
Disk Starage (DADS) system which will be faster and more 
reliable. The message file capacity will be reduced to 
approximateiy twenty-five days worth, which will be employed 
for reference routing for over-the-counter traffic. [Refs. 
Zi and 24} The installation of the DADS in Honolulu has 
provided an excellent illustration of the necessity of 
evaluating the total situation. The maintenance of a 
constant physical environment, especially in regard to 
temperature, is a critical factor in the operation of a 
computer system. When the DADS was installed, tke result 
was a modification of the heat load in the computer area. 
This heat imbalance began to cause problems in performance 
of the system's perpherial equipment, such as disk drive 
heads. In -crder to rectify the difficulty, the computer 
room air conditioning was re-ducted at the cost of $10,000. 
A computer system is a delicately balanced entity, and all 
aspects of its operation and maintenance must be carefully 
examined and evaluated prior to the implementation of 
Changes. Adequate preplanning can prevent problems and 


outages. 


Be. CODE TRANSLATION 


Code translation is the term used to describe the 
process whereby the code used by terminal devices is 


converted into the code utilized by the central processor. 
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The extensive use of this process could be considered a 
source of major inefficiency of the current structure of 
NAVCOMPARS. In its effort to compete with IBM, RCA designed 
its Spectra 70 series to employ the same instructions, 
formats and character codes as the IBM 360. [Ref. 3] The 
Result of this is that the 70/4Se¢PU utilizes EBBCDEGeas its 
internal processing code. rn contrast, the major 
communications code employed by the federal government on 
its lines is ASCII. 


Between 1959 and 1962, the 7-level code designated ASCII 
was developed in order to provide some means of standardized 
coding capability between products of various computer 
manufacturers, IBM, realizing that standardization between 
processors might cut into its dominant position, voted 
against the adoption of ASCII as a standard. Instead, it 
developed an 8-level code, EBCDIC, which it utilized for the 
IBi 3690 series. This code was adopted by other 
Manufacturers, including RCA for its Spectra 70 series. The 
federal government was a major supporter of the movement to 
designate ASCII as an official standard; to give impetus to 
this development, President Johnson in 1968 released a 
memorandum estabiishing ASCII as a federal standard. All 
computers Drought into the government inventory after 1 July 
1969 were reguired to have the capability to use ASCII. in 
an effort to prevent ASCII from becoming the only standard, 
IBM endeavored to limit ASCII to being recognized only as a 
communications standard. In 1969 the strict position of 
President Johnson was modified, and the government directed 
that ASCII was required only for communications. The 
Mandatory use of ASCII as an internal processing code could 
be waived by an agency head if efficiency could be improved 
by not using ASCII; however, a translator must be provided 
which would convert thd internal code used to ASCII for 
transmission over the communications lines. This decision 


has resulted in performance degradation because code 
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translation is wasteful of the resources of the CPU. [ Ber. 
3] 


NAVCOMPARS 1S especially hindered by this process of 
code translation. Not only must it contend with the ASCII 
code used in the Autodin systen, but it also must handle 
code conversion of the five level baudot of the high 
frequency links. In that these requirements for code 
conversion are relatively locked in due to the prevailing 
equipment inventories and other governmental requirements, 
the problem is to accomplish code conversion in the least 
wasteful manner. AS currently configured, the Receive 
Control Subsystem manages code conversicn for incoming 
messages and the Transmission Control Subsystem performs 
this function on outgoing messages. Both these subsystens 
are core~resident, thereby utilizing the limited and 
expensive core memory for a standardized function performed 


twice for every message. 


As previously stated, additional programas are 
contemplated for NAVCOMPARS which would increase demands on 
the limited amount of core available. The UNIVAC 90/60 
processor currently has the option to use either EBCDIC or 
ASCII. [Ref. 5] Because of the established use of ASCII in 
the Autodin network, it is strongly advocated that the 90/60 
be configured so that ASCII is the internal processing code. 
Furthermore, the rapid development of mini-computers and the 
corresponding decrease in thelr cost present an alternative 
possibility which should be seriously explored. 
Concentrators which are Mini-computers have been created 
which could handle the code translation function on a more 
economical basis, thereby freeing the CPU for more essential 
and less routinized work. [Ref. 6] Applicable cost analysis 
is beyond the scope of this paper, but it is recommended 
that action be taken to investigate the potential of using a 


Mini-computer with a code conversion capabilbity in 
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conjunction with the UNIVAC series 70/45 and 90/560 
processors. 


C. SOFTWARE 


The operating system for the NAVCOMPARS was supplied 
by the manufacturer, whereas the programs dealing with the 
unigue ccmmunications functions were written by NAVCOSSACT. 
The Navy experiences a distinct advantage by having software 
programs individually tailored to its functions and 
applicable hardware. Software designed for specific 
activities results in much faster response time, although 
the investment in software programs is much higher than if 
Standardized off-the-shelf software is used. The 
maintenance of uniform software at all NAVCOMPARS sites not 
only increases interconnectivity, but it also is the nost 
cost effective method of developing the extensive programs 
needed fcr a major system like NAVCOMPARS. The software 
currently operating on the Series 70/45 is compatible with 
the requirements for the Series 90/60 processor; therefore, 
Staying with a UNIVAC follow-on computer will minimize 


software transition costs. 


The programming for this system was done in two 
different ccnmputer languages. Assembly language code is 
employed for those programs which are used for message 
processing within the core. The advantage of assembly 
language is that it allows for faster response time and 
provides for conservation of core; its main disadvantage is 
Ghat 28 is “dafficwit to code. Most of the NAVCOMPARS 
Support pragrams are done in the Common Oriented Business 
Language (COBOL) because these programs are the ones with 
Which the on-site operators are directly involved. COBOL 


was designed to be easy to use and it is weil adapted to an 
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external environment like a NAVCOMMSTA where the Majority of 
users are not computer experts. COBOL is not an ideal 
communications language in that it is a verbose language 
Which should not be used where speed and compactness of code 
are salient features. [Ref. 7] NAVCOMPARS has a mix of 80% 
assembly language and 20% COBOL programming. This mix 
roughly reflects the division between operating and support 
programs. 


D. HUMAN FACTORS 


In accordance with the proposition that a communications 
Manager must treat with the whole environment in order to 
gain maximum performance from an automated system, attention 
Will now ke focused on the human element. This is extremely 
important in an automated system which depends upon a myriad 
of sources fcr input. A well constructed system design is 
essential tc create a viable package, but the human factor 
can be a critical feature. An automated network places 
additional requirements on operators as to degrees of 
precision needed for efficient thruput. Consequently, these 


reguirements must be identified and publicized. 


Humans are flexible and adaptable, and they can supply 
corrections to plain text mistakes easily and quickly; by 
contrast, computers have rigid specifications and are very 
unforgiving of even minor errors. NAVCOMPARS was designed 
to compensate as much as possibie for human mistakes, as 
well as for transmission errors and garbles. As delineated 
in Chapter Four, the programs have been written so that the 
computer processing immediately refers any error or 
unaccountable situation to the VDT operator for manual 
resolution. This prevents messages from being sent back to 


the originator, but it also slows down processing. The 
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queue for the VDT operators is one point of congestion which 
can be readily identified. Errors which require manual 
intervention can be the result of improper format used by 
the originator, equipment malfunction (particularily the 
OCRS) or poor quality high frequency transmission path. 
fret. 25] 


One of the input principles delineated in Reference 19 
is that the volume of data to be produced by humans’ should 
be reduced. In contradiction to this idea, NAVCOMPARS is a 
system in which all imput is produced by human operators of 
varied training and talent. To compound this situation is 
the problem that absolute determination can not be made as 
to the cause of the errors. 70% of all errors occurein 
those format lines (6, 7 and 8) which use the standardized 
Plain Language Address (PLA) for command short titles. 
(Ref. 25] Some portion of the above error total can be 
blamed upon commands not following the prescribed short 
titles delineated in the Plain Language Address Directory 
(PLAD) contained in NTP 3. Some degree of flexibility has 
been built into the system through the inclusion of the 
Aiternate Spelling File, which incorporates common short 
title mistakes and connects these with the correct routing 
indicator. Improvements in compliance with the PLAD and 
general format conformity can only be achieved through the 
efforts of each individual command. Not only communications 
personnel, but also message drafters and releasors must be 
made aware of the consequences of careless performance. 
Performance from an individual point of view strongly 
depends upon the individual's perception of the importance 
of the work being accomplished and of his particular role 
Within the whole. [Ref. 19] The average radioman onboard a 
Ship or small command is unable to visualize how his daily 
work fits into the rather remote goal of "improving Naval 
communications through automation." Communications officers 


have a responsibility for ensuring that their personnel 
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understand their contribution toward improving their 
command's communications record. The division level is the 
logical place to start because this is where the work is 
actually performed. The average radioman must perceive that 
he is a vital link in the Navy's communications network and 
that his adherence to prescribed procedures is beneficial to 
himself and his ship. The NAVCOMMSTA has the functicn of 
supplying all available performance feedback and orientation 
on automated procedures and requirements. NAVCCMMSTA 
Honolulu has personnel who are available to indoctrinate its 
subscribers in the methods and procedures prescribed fcr the 
input into the NAVCOMPARS. This approach should be 
instituted at all NAVCOMPARS sites. The area of 
performance motivation affects every facet of the Navy 
today, but it is a subject which is easier to discuss than 
to isolate solutions. However, the human element should not 
be neglected; if personnel can be motivated to fulfil their 
role, communications automation can benefit froa 
improvements which depend not at ali on increased 


expenditures or more exotic equipment. [jRefs. 8 and 14} 


E. SUMMATION 


The initial NAVCOMPARS site at NAVCOMMSTA Norfolk 
became operational in June 1973; since then additional 
systems have kecome operational at NAVCOMMSTAS Honolulu, 
Guam and Naples, Italy. The fifth and final NAVCOMPARS is 
slated for installation at NAVCOMMSTA San Francisco in 1977. 
The NAVCOMPARS has evolved into a successful system which 
has accomplished its stated objectives of providing faster 
processing tines and of shifting the majority of tine 
consuming message handling tasks from fleet units to shore 
based communications stations. NAVCOMFARS is not 4 


perfect system: software bugs are still being uncovered and 
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hardware modifications have already taken place. However, 
the system has recorded a hardware/software reliability of 
98%, and it has achieved an error rate of less than 1% of 
all messages processed. [Ref. 21] It is a dynamic. systen 
which is continuing to grow and to assume new capabilities. 
Projected enhancements include the consolidation of special 
intelligence and general service traffic, the installation 
of the RIXT terminals and full implementation of the IXS 
progran. 


This thesis has constructed a flowchart model of the 
message handling procedures which could be used as an 
instructional tool to introduce communications personnel to 
the characteristics, capabilities and limitations of 
communications automation. Specific recommendations have 
been made throughout the body of the text and will not be 
repeated here. Perhaps the most important aspect of this 
thesis is the delineation of the limitations of automation. 
Continued benefits for naval telecommunications through 
system automation will ensue only if system requirements are 
understood and supported py all users. The foilowing 
NAVTELCOM statement issued in 1973 is still valid today 
{Ref. 4]: 


"Success depends upon SEELCE adherence to 
prescribed procedures and formats, most of which 
ace carrently effective. Failure to comply will 
negate the advantage of automation." 


ee 
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